Blog | On the Web | About me

Search 

Feeds 

rss entriesRSS/Feed for Content
rss entriesRSS/Feed for Comments

Recent articles 

Recent comments 

Tag cloud 

Archives 

Blog roll 

Websphere Portal Development options - The big picture - Part 2 

Second part in my overview ... (first part here)

4. Lotus Component designer

This is "the great promise". Last year IBM released this great tool. It was the J2EE tool for Lotus developers. It mimics Lotus Designer concepts to build J2EE portlet
components to be used inside the composite applicatiton framework of websphere portal.
Component designer first appeared as Workplace Designer. It was the tool to build components for the worplace system.

Amongst the great features component designer supports:

  • Web service client builder
  • Relational DB connectivity
  • XML datastore based on "designer database" (a database domain in WebSphere Portal)
  • Domino database access
  • Composite application wiring
  • Composite application roles

Development is done in JavaScript and the API mimics the Lotus Notes/Domino API.

The result of development are portlet applications to be deployed inside IBM Workplace Services (R.I.P.) or WebSphere Portal with designer extensions (Portal Express 6.0.1 or Portal 6.0 + Designer runtime).

Once the portlet is deployed it can be used in the conext of the Composite Application builder and portlet features can adapt to the application (composite application) context in respect to roles, user access and so on.

Internally (based on my study) Component designer used a JSF based framework and a "XSP" User interface tag library that would eventually allow for "cross-device" deployment, also Components created in Component Designer where using the Eclipse OSGI framework.

Based on these elements I suppose it was designed to:

  • Run inside portal
  • Run inside the Notes Client/Expeditor runtime, maybe with OS native user interface using XSP
  • Be deployable as Eclipse plugin in expeditor
  • Be deployable as Plugin inside Portal using OSGI as an alternative to common WAR deployment (extra manifests are included).
Today Component Designer seems to be getting cold on Notes.Net/Lotus.com and no news were announced in the last few months. Anyway the product is very interesting and I think we'll see it come back in Domino Deigner Next (8.5 ?). Domino Next should be based on eclipse and would be the perfect place to have Component Designer available as a plug-in.

Note: Most of what I've written is "speculation". I expect this to be realistic. But you never know ...

5. Domino Application Portlet (DAP)

Domino Application Portlet made is appearence around the time of WebSphere Portal 5.x and is a portlet that aims to simplify integration of Domino Web Applications (limited integaration).

The "technological" principle behind DAP is that of an intelligent reverse proxy that can surface a Domino Web Application by analyzing an re-publishing it's HTML code based on rules.

So when you put a DAP instance on your portal you:

  • Define the url of the application (HTTP/S, host, port, db path)
  • Define the way to authenticate (LTPA SSO / Basic / Credential Vault)
  • Define the title of the portlet instance for display in the portal
On top of these settings a set of  "regular expressions" controls how your HTML is re-written and published to clients (browsers) in the context of the portlet.

Always remember that in DAP:

  • The portlet is stateless, if you move to another page and get back or the page is reloaded you find yourself on the "starting page" for your domino app
  • No wiring is available from your DAP and the portal, this mean no integration is available
  • Out of the box regular expressions are for standard domino templates (teamroom, doc library) you may need to add more for other/your apps.

6. Websphere Portal Application Integrator (WPAI)

Websphre Portal Application Integrator was an early technology (available since Portal 4.0) with the objective of allowing portal users to build application integration directly into portal using portlets as a development environment.

WPAI included support for Domino / SAP / Siebel / SQL connections and simplified integration. It supported Click to action for interportlet communication.

WPAI used a set of porlets called "builders" to create new applications that were created by copying into portatl instances of deployed "templates". The builder configured these templates and made them available as indipendent portlet to be used.

Internally these templates were using struts and portal API.

Today (Portal 6.0) is not including anymore WPAI since the available options (mostly Portlet Factory) offers far better results (with an higher cost indeeed).


Conclusion

That's all for my "short" introduction to  WebSphere Portal development options. A lot of things are coming in the near future from IBM so stay tuned. Portal maturity is a fact today, companies and customers needs the portal but many still doesn't get it.

A lot of opportunities are available for us (Architects, Developers, Consultants, Organization experts and so on. Don't miss them)



Comments (0)
Daniele Vistalli December 2nd, 2007 09:40:00